CMake: Remove hardcoded warnings list and forcing -Werror on library builds #1324
Conversation
…builds The CMake buildsystem should be completely reviewed to properly match what is done by SCons, instead of making its own arbitrary decisions on how godot-cpp should be compiled. Currently the SCons setup doesn't include warning options, so CMake shouldn't either. Options similar to upstream Godot's SCons setup could be added, and then replicated for CMake.
akien-mga
added
enhancement
|
I see that #1007 aims at adding warning options to SCons - so once it's finalized and merged, this can be revisited to add the same warnings to CMake. I insist that if we support multiple buildsystems, we should strive to make them produce the exact same output. So they need to take the exact same input. |
I agree that this is a problem. Right now, the majority of open PRs on godot-cpp are build system related. And a sizeable percentage are cmake related (they aren't all tagged, so I can't easily get a count, but it could even be a majority). But, personally, I don't just know cmake, so beyond the simplest changes, I can't personally review them either. We really need someone on the GDExtension team who understands and cares about cmake, in addition to understanding how the scons build system works so we can be sure that both are working in the same way with the same overall philosophy. |
|
Cherry-picked for |
|
Cherry-picking to 4.1 in #1373 |
2 participants
The CMake buildsystem should be completely reviewed to properly match what is done by SCons, instead of making its own arbitrary decisions on how godot-cpp should be compiled.
Currently the SCons setup doesn't include warning options, so CMake shouldn't either. Options similar to upstream Godot's SCons setup could be added, and then replicated for CMake.
This kind of issue is exactly why I'm against having multiple buildsystems. It's very difficult to keep them in sync, especially since officially we only commit to maintaining SCons, yet many users reach straight for CMake as more familiar to them (or usually more familiar to their IDE...).
If we really want to support CMake (which can make sense for something used to interface with thirdparty codebases, often using CMake), then it probably needs to be redone from scratch by someone who understands and cares about the SCons buildsystem, and can strive to keep them in sync. That won't be me :)